Closed
Bug 1159280
Opened 10 years ago
Closed 10 years ago
TSan: data race netwerk/protocol/websocket/WebSocketChannel.cpp:3156 WebSocketChannel::Close
Categories
(Core :: Networking: WebSockets, defect)
Tracking
()
RESOLVED
FIXED
mozilla41
Tracking | Status | |
---|---|---|
firefox41 | --- | fixed |
People
(Reporter: froydnj, Assigned: michal)
References
(Blocks 1 open bug)
Details
(Whiteboard: [tsan])
Attachments
(2 files)
17.35 KB,
text/plain
|
Details | |
11.42 KB,
patch
|
mcmanus
:
review+
|
Details | Diff | Splinter Review |
The attached logfile shows a thread/data race detected by TSan (ThreadSanitizer).
* Specific information about this bug
The specific fields getting read/written here are bitfields in WebSocketChannel. I presume what the compiler is doing is grabbing all the bitfields at once with a 16-bit read, and then twiddling the particular bit of interest, hence the bitfields involved in the read/write are different.
I am a little surprised that TSan reports no mutexes held during either the read or write side of these bitfields.
Jason, can you find someone to look at this bug?
* General information about TSan, data races, etc.
Typically, races reported by TSan are not false positives, but it is possible that the race is benign. Even in this case though, we should try to come up with a fix unless this would cause unacceptable performance issues. Also note that seemingly benign races can possibly be harmful (also depending on the compiler and the architecture) [1][2].
If the bug cannot be fixed, then this bug should be used to either make a compile-time annotation for blacklisting or add an entry to the runtime blacklist.
[1] http://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong
[2] _How to miscompile programs with "benign" data races_: https://www.usenix.org/legacy/events/hotpar11/tech/final_files/Boehm.pdf
Flags: needinfo?(jduell.mcbugs)
Comment 1•10 years ago
|
||
michal seems to be taking on ws maint.. ni?
Flags: needinfo?(michal.novotny)
Comment 2•10 years ago
|
||
Michal is taking this.
Note that I'd be fine with splitting out all of these bitfields into separate variables as needed here (and it would probably be best to be conservative and default to that, and only combine vars into bitfields when we've audited the code to know that it's safe.)
Assignee: nobody → michal.novotny
Flags: needinfo?(jduell.mcbugs)
Assignee | ||
Comment 3•10 years ago
|
||
Only few variables from the bitfield are accessed on a single thread. I've kept those as bitfield. The rest I made atomic. I'm not sure that it is enough to synchronize them separately, but I didn't find any exact scenario where it could be a problem.
Flags: needinfo?(michal.novotny)
Attachment #8609369 -
Flags: review?(mcmanus)
Comment 4•10 years ago
|
||
Comment on attachment 8609369 [details] [diff] [review]
patch v1
Review of attachment 8609369 [details] [diff] [review]:
-----------------------------------------------------------------
thanks
Attachment #8609369 -
Flags: review?(mcmanus) → review+
Comment 6•10 years ago
|
||
Status: NEW → RESOLVED
Closed: 10 years ago
status-firefox41:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
Depends on: 1168221
You need to log in
before you can comment on or make changes to this bug.
Description
•